Skip to content

chore(deps): update terraform unifi to v0.55.0 - #810

Open
amriksd[bot] wants to merge 1 commit into
mainfrom
renovate/unifi-0.x
Open

chore(deps): update terraform unifi to v0.55.0#810
amriksd[bot] wants to merge 1 commit into
mainfrom
renovate/unifi-0.x

Conversation

@amriksd

@amriksd amriksd Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
unifi (source) required_provider minor 0.53.00.55.0

Release Notes

ubiquiti-community/terraform-provider-unifi (unifi)

v0.55.0

Compare Source

✨ Features
  • unifi_ap_group: manage AP group membership. Full CRUD, complementing the existing read-only data source. Which APs belong to a group was fixed in the controller UI: the data source could read a group, but nothing could create or edit one, so unifi_wlan.ap_group_ids could only reference groups built by hand. The resource writes membership through the v2 apgroups API. device_macs reuses the unifi_client MAC type, so AA-BB-… and aa:bb:… read back equal rather than churning the plan on every refresh. Import takes the group ID, or site:id for a non-default site (#​359, go-unifi#52).
🐛 Bug Fixes
  • unifi_firewall_policy: fix creating a policy that matches an IP group failing with api.err.EmptyFirewallDestinationIps (400). A source/destination referencing an address group via ip_group_id (#​316) must be sent with matching_target_type = "OBJECT", but the #​293 derivation back-filled an empty type as SPECIFIC for any non-ANY match — and on create the type is never controller-assigned, so every create with ip_group_id was rejected and only literal ips worked. A group reference now derives OBJECT, also overriding a stale ""/"ANY"/"SPECIFIC" carried in state so switching an existing policy from literal ips to a group reference works on update too; a controller-assigned OBJECT/LIST is still preserved (#​365, #​316, #​293)
  • unifi_device: carry switch_vlan_enabled, radio_table[].vwire_enabled, and mesh_sta_vap_enabled in the update PUT. The update PUT was assembled from a minimal Device that dropped several configured fields, so the controller never received them and every apply that set one failed with inconsistent result after apply (was cty.True, but now cty.False). Fixed for: switch_vlan_enabled (the "Port VLAN" toggle, e.g. an AP with a built-in switch, where the toggle is what makes VLAN tagging take effect on the built-in ports); radio_table[].vwire_enabled (the "Mesh Parent" toggle — the whole radio_table was omitted from the minimal PUT, dropping every radio sub-field); and mesh_sta_vap_enabled (the "Mesh Connect" toggle, newly added to the unifi_device schema as an Optional + Computed bool). All are now carried in the PUT body when configured. omitempty (at every level, including radio_table) keeps a false/empty off the wire, so it never disturbs the controller default. Verified against a real controller (#​363)
  • unifi_device / unifi_setting: stop controller-managed lists churning to "known after apply" on unrelated edits. Several Optional + Computed lists were replanned as (known after apply) whenever any other field on the same resource changed — a spurious diff (the same class as #​338). They now use UseStateForUnknown, keeping their prior value unless explicitly changed: unifi_device radio_table and outlet_overrides, and unifi_setting contents (syslog facilities), server_names (DoH), enabled_categories / enabled_networks (IPS), and network_ids (IGMP snooping).
  • unifi_ap_group: allow empty membership and stop empty groups reading back as null. device_macs was Required with a SizeAtLeast(1) validator, and the read mapped an empty member list to SetNull — so a group the controller legitimately allows to have zero members (the API returns 201 for an empty membership) could not be authored, and importing one surfaced as an empty-vs-null inconsistency. device_macs now accepts an empty set and reads empty back as an empty set. The built-in default "All APs" group (which the controller marks read-only) is documented as non-editable through the resource.

v0.54.1

Compare Source

🐛 Bug Fixes
  • unifi_radius_profile: make auth_server / acct_server ip optional so the default profile can be imported. The controller-managed default RADIUS profile (created when a gateway RADIUS/VPN service is enabled, with use_usg_auth_server = true) returns a server entry without an IP. ip was Required, so re-declaring an imported profile failed with The argument "ip" is required, and an empty IP read back as "" instead of null. ip is now Optional and an absent IP maps to null, so the default profile round-trips cleanly (#​356)

v0.54.0

Compare Source

✨ Features
  • unifi_network: expose the network purpose (corporate, guest, vlan-only). A new Optional + Computed attribute. The provider previously hard-coded corporate (or vlan-only for a third_party_gateway), so a guest network could not be authored and a controller-assigned guest purpose was silently fought on every apply. purpose is now sent when configured and read back from the controller. Note: on Zone-Based-Firewall controllers the purpose is coupled to the firewall zone — a guest network only keeps purpose = "guest" while it belongs to the guest/Hotspot zone (assign it there via unifi_firewall_zone); placed in a non-guest zone the controller rewrites it back to corporate. third_party_gateway = true still forces vlan-only for backward compatibility (#​276)
  • unifi_firewall_policy: make connection_state_type / connection_states author-settable. Both attributes were Computed-only, so setting them returned Invalid Configuration for Read-Only Attribute — you could not author a policy scoped to a specific connection state. They are now Optional + Computed: leave them unset and the controller manages them as before, or set connection_state_type = "CUSTOM" with connection_states = ["NEW", …] (or RESPOND_ONLY) to author, for example, a NEW-only logging/deny policy that coexists with stateful returns in a zone-based firewall. Values are validated (ALL/RESPOND_ONLY/CUSTOM; states NEW/ESTABLISHED/RELATED/INVALID) and still round-trip on update (#​351)
  • unifi_wan: expose networkgroup (WAN, WAN2, …). A new computed-by-default attribute identifying which WAN group an interface belongs to. The provider previously hard-coded wan_networkgroup/attr_hidden_id to WAN, so updating a secondary uplink (WAN2) collided with the primary and the controller rejected the PUT (api.err.WanConfigurationForNetworkGroupAlreadyExists). The group is now read from the controller and preserved in the update payload (UseStateForUnknown, so an imported WAN2 needs no explicit config), making multi-WAN setups manageable (#​334)
🐛 Bug Fixes
  • unifi_network: fix inconsistent result after apply on multicast_dns for non-vlan-only networks. Some controllers (notably UniFi OS gateways) ignore the per-network mdns_enabled flag and always store false, so a configured true conflicted with the post-apply read. The corporate-network read path now preserves the configured value (the vlan-only path already did), falling back to the controller's value only when it was left unset (#​282)
  • unifi_wan: fix inconsistent result after apply on wan_dslite_remote_host_auto. The controller can force this field back to true server-side, so the post-apply read conflicted with a user-configured false. The create/update paths now re-assert the configured DS-Lite values on the post-apply state (the update path applied its write-preserve before the API round-trip, so the controller value won); the next refresh still reconciles with the controller (#​281)
  • unifi_firewall_policy: stop source/destination match lists churning to "known after apply" on unrelated edits. Changing any other field (e.g. index or protocol) replanned network_ids, client_macs, ips and web_domains as (known after apply) — showing a spurious diff and risking the controller recomputing them. These Computed attributes now use UseStateForUnknown, so they keep their prior value unless explicitly changed (#​338)
  • unifi_device: fix LED updates failing with inconsistent result after apply. The update PUT body was assembled as a minimal device that dropped the LED override fields (led_override, led_override_color, led_override_color_brightness), so the controller kept the old values and the post-apply read conflicted with the plan. They are now included in the PUT, and — because the controller applies LED changes to APs asynchronously — the update path also re-asserts the planned LED values on the post-apply state, leaving the next refresh to reconcile with the controller (#​337)
  • unifi_device: fix mgmt_network_id (Network Override) never persisting. The update PUT was assembled from a minimal Device that dropped a configured mgmt_network_id, so the controller never received it: every apply that set it failed with inconsistent result after apply, and the per-device management VLAN could not be set through the provider. The field is now carried in the PUT body when configured. omitempty keeps a null value off the wire, so it never reintroduces the #​177 zero-value rejection. The tag-upstream-first connectivity requirement documented in #​330 still applies (#​329)
  • unifi_wan: fix inconsistent result after apply on dns address fields (primary, secondary, ipv6_primary, ipv6_secondary). When no DNS server is configured the controller persists and returns an empty string "", but these Optional fields plan as null, so the post-apply read conflicted with the plan (e.g. after import with IPv6 DNS preference auto). The read now normalizes "" (and a nil pointer) to null, so unset addresses stay null and a real address still round-trips (#​333)
  • unifi_firewall_policy: make index read-only to stop inconsistent result after apply and a perpetual diff. Pinning index failed: the controller ignores a client-supplied value and always appends the policy at the end of its source/destination zone-pair, so the post-apply read (e.g. 1001010020) conflicted with the plan and then looped forever. Verified against a real UniFi OS 10.x controller — the supported integration API rejects index as input and exposes no reorder operation, so policy ordering cannot be managed through the provider. index is now Computed (controller-assigned) and the provider no longer sends it; reorder policies in the UniFi UI if needed (#​348)

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@amriksd
amriksd Bot requested a review from AmrikSD as a code owner July 2, 2026 13:02
@amriksd
amriksd Bot force-pushed the renovate/unifi-0.x branch from 8911adb to bfc800c Compare July 6, 2026 14:27
@amriksd amriksd Bot changed the title chore(deps): update terraform unifi to v0.54.0 chore(deps): update terraform unifi to v0.54.1 Jul 6, 2026
@amriksd
amriksd Bot force-pushed the renovate/unifi-0.x branch from bfc800c to 86f28fe Compare July 11, 2026 11:53
@amriksd amriksd Bot changed the title chore(deps): update terraform unifi to v0.54.1 chore(deps): update terraform unifi to v0.55.0 Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants